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ABSTRACT 


As communication in tactical arenas continues to trend from serial to Internet 
Protocol (IP) based, the necessity for tactical programs of record to embrace IP 
communications becomes more and more imperative. While many Marine Corps 
tactical communications programs of record already recognize this trend and its 
significance, some are affected more heavily than others. 

Numerous advantages exist for transitioning from Internet Protocol version 
4 to Internet Protocol version 6, and a top-down transition makes most sense for 
deployed and deploying units; the Data Distribution System-Modular is the 
system best suited to take on this role. 

The Naval Postgraduate School’s Center for Network Innovation and 
Experimentation (CENETIX) and Tactical Network Topology (TNT) field 
experimentation program, along with the Marine Corps Tactical Systems Support 
Activity (MCTSSA), can take on this task of transitioning the Tactical Marine 
Corps to IPv6; the commonality of the Defense Research Engineering Network 
(DREN) will allow for collaboration and testing that will greatly benefit our war 
fighters. 
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I. INTRODUCTION 


A. BACKGROUND 

1. TheDDS-M 

The Tactical Data Networks (TDN) Project Officer at Marine Corps 
Systems Command (MCSC) identified the need for interoperability assessments 
on the Data Distribution System-Modular (DDS-M). The results of these 
assessments will determine the extent of joint interoperability for the DDS-M 
when transitioning from Internet Protocol version 4 (IPv4) to Internet Protocol 
version 6 (IPv6). 

The DDS-M was previously tested for interoperability by Joint 
Interoperability Test Command (JITC), but IPv6 testing was not completed. 
Specific protocols tested include: HTTP, FTP, SMTP, VoIP, and VTC IPv6 
requirements. Follow-on participation will allow additional IPv6 testing to continue 
and address previously identified shortfalls. 

The Marine Corps deploys Marine Air-Ground Task Forces (MAGTFs) 
throughout the world to fulfill operational requirements, often in joint/combined 
operating environments. During these deployments, MAGTFs require access to 
strategic, theater, and tactical communications networks and information systems 
that support functional capabilities for command, control, communications, 
administration, logistics and intelligence. TDN DDS is the data communications 
backbone for the MAGTF augmenting and extending Defense Information 
System Network (DISN) services. 

The DDS-M was developed to support the MAGTF command and control 

communications mission objectives. It was designed to provide Internet Protocol 

(IP) based data routing, information processing and storage, as well as network 

extension capabilities for deployed Marine Corps forces. The DDS-M features a 

flexible and modular Local Area Network (LAN) capability to provide services to 

the Marine Corps Tactical Data Systems (TDS) and other DDS-M systems. The 
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DDS-M can function as the file server supporting typicai LAN services such as 
fiie sharing and electronic mail. A DDS-M suite aiso has the switching, 
processing, and storage capacity, along with the flexibility to support operations 
at a single security levei. 

A DDS-M suite can operate from the Sensitive-But-Unclassified (SBU) up 
to the Top Secret (TS)/Sensitive-Compartmented-lnformation (SCI) level and will 
contain an integral Inline Network Encryption (INE) device to support tunneling. 
Components of the DDS-M are integrated by functional groups into transit and 
storage cases for unit transport (Figure 1). 



Figure!. DDS-M 


The LAN Extension Module (LSM), LAN Services Moduie and the 
Enterprise Switch Module (ESM) provide Layer 2/3 functionality to the DDS-M. 
The WAN Service Moduie provides Layer 3 functionaiity. The Media Distribution 
Moduie (MDM), Media Control Module (MCM), Application Service Moduie 
(ASM), and Data Storage Module (DSM) provide Layer 4 functionaiity to the 
DDS-M. The Power Moduies and COMSEC Modules will not be addressed in 
this thesis as they are outside the scope of the study. The Information Assurance 
Moduie will not be addressed in this thesis, as it is not yet fielded by the Marine 
Corps. 
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2. The Protocols Compared 


Table 1 outlines many of the differences between IPv4 and IPv6. There is 
a give and take that can be seen from an understanding of this transition. 


IPv4 

IPv6 

Source and destination addresses are 32 bits (4 
bytes) in length. 

Source and destination addresses are 128 bits (16 
bytes) in length. 

IPSec support is optional. 

IPSec support is required. 

No identification of packet flow for QoS handling by 
routers is present within the IPv4 header. 

Packet flow identification for QoS handling by 
routers is included in the IPv6 header using the 

Flow Label field. 

Fragmentation is done by both routers and the 
sending host. 

Fragmentation is not done by routers, only by the 
sending host. 

Header includes a checksum. 

Header does not include a checksum. 

Header includes options. 

All optional data is moved to IPv6 extension 
headers. 

Address Resolution Protocol (ARP) uses broadcast 
ARP Request frames to resolve an IPv4 address to a 
link layer address. 

ARP Request frames are replaced with multicast 
Neighbor Solicitation messages. 

Internet Group Management Protocol (IGMP) is used 
to manage local subnet group membership. 

IGMP is replaced with Multicast Listener Discovery 
(MLD) messages. 

ICMP Router Discovery is used to determine the 

IPv4 address of the best default gateway and is 
optional. 

ICMP Router Discovery is replaced with ICMPv6 
Router Solicitation and Router Advertisement 
messages and is required. 

Broadcast addresses are used to send traffic to all 

nodes on a subnet. 

There are no IPv6 broadcast addresses. Instead, a 
link-local scope all-nodes multicast address is used. 

Must be configured either manually or through 

DHCP. 

Does not require manual configuration or DHCP. 

Uses host address (A) resource records in the 

Domain Name System (DNS) to map host names to 
IPv4 addresses. 

Uses host address (AAAA) resource records in the 
Domain Name System (DNS) to map host names to 
IPv6 addresses. 

Uses pointer (PTR) resource records in the IN- 
ADDR.ARPA DNS domain to map IPv4 addresses to 
host names. 

Uses pointer (PTR) resource records in the 

IP6.ARPA DNS domain to map IPv6 addresses to 
host names. 

Must support a 576-byte packet size (possibly 
fragmented). 

Must support a 1280-byte packet size (without 
fragmentation). 


Table 1. Comparison of IPv4 and IPvS^ 


^ “Transition Planning for Internet Protocol version 6 (IPv6),” accessed July 5, 2010, 
http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pclf. 
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While the comparison mainly paints a picture that IPv6 is an improvement 
from IPv4 in aii ways, it does not take into account how the change in header 
structure and size (IPv4 being 20 octets and IPv6 being 40 octets) may impact 
network performance on tactical communications iinks where bandwidth is 
generaiiy iimited. 


IPv4 header 


Version | IHL | Type of service 

Total length 

Indentlfication 

Flags I Fragment offset 

Time to live Protocol 

Header checksum 

Source address 

Destination address 

Options 

Padding 


Vcraion; protocol version number 

HL; IP Header length in 32-bit words 

Type of service; Contains priority information 

Total length: Total length of the datagram In bytee 

Identification: When an IP packat ia segmented into multiple fragments, 

each fragment is given the same identification 

Raga: When a packet ia fragmented, all fragments except the 

last one have this bit set 

Fragment offset: The fragment's position whhin the original message 

Time to liva: Hop count, decremented each time the packet rsachea a new router 

Protocol: IdentHiee which transport layer protocol Is being used for this packet 

Header checksum: Verifies the content of the IP header 

Source address: IP address of the originating host 

Destination address: Dsstinatbn address of ths receiving host 

Options; Used to octend functionally of IP 

Padding: Additional Instructions not covered in the other fields; if an option 
does not fill up a 32-bit word, it will be filled In with padding bits 


IPv6 header 


I Version 

I Traffic class I 

Flow label 

Payload length 

Next header Hop limit 


Source address 


Destination address 


Version; kitemet protocol version number 
Traffic class; For prioritizing types of traffic 

Row labsl: Allows a host to label sequences of packets for which It requests 
special handling by the IPv6 routers 

PaylotKl length: Ths length of ths packet following the IPv6 header 

Next header Identifies the type of header Immediately following the IPv6 header 

Hop limit: Decremented by one by each node that forwards the packet; 
the packet Is discarded if Hop Limit is decremented to zero 

Source addrsea: IP address of the originating host 
Destination address: Dsstination address of the receiving host 


□ Field name kept from IPv4 to IPv6 

□ Field not kept In IPvS 

I I Name and position changed in IPv6 


I New field in IPv6 


Figure 2. IPv4 and IPv6 Headers Compared^ 


B. PURPOSE OF STUDY 

The purpose of this thesis is to design and develop a test plan and 
architecture that will assess the IPv6 functionality, conformance, performance, 
security, and interoperabiiity of the DDS-M. The resuit wiii be a thorough and 
appropriate test pian to determine whether the system meets the following 
requirements as defined by JITC: 

a) an IPv6 Capable Product 

b) Joint Interoperabiiity Certification 


2 “Transition Planning for Internet Protocol version 6 (IPv6),” accessed July 5, 2010, 
http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pclf. 
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C. TEST OBJECTIVES 


The objectives of the test will be to verify/demonstrate the interoperability 
of DDS-M in a Joint Environment when transitioned from IPv4 to IPv6 in the 
following areas: 

1. IPv6 functionality 

2. IPv6 conformance 

3. IPv6 performance 

4. IPv6 security 

D. TEST SCOPE 

The testing will encompass various aspects of the system and 
components. The system is comprised of multiple components that fall into 
different IPv6 Product Classes, as defined in the DoD IPv6 Standard Profiles for 
IPv6 Capable Products version 6.0. Each of these product classes have unique 
mandatory and optional requirements and will be evaluated separately. The test 
will be an Iterative process to accurately evaluate both the individual components 
and the system in its entirety. 

The test is divided into four phases. The focus of Phase 1 is to assess 
functionality and performance of IPv6 applications, services, transport and 
routing. This phase will test three network scenarios; IPv4, dual-stack, and IPv6 
native. The focus of Phase 2 is to assess conformance of individual system 
components. Phase 3 will assess security aspects of IPv6 products. Phase 4 is 
interoperability testing; during this phase, information exchanges for voice, video, 
and data will be assessed in unclassified and unclassified encrypted networks. 

E. TEST CONSTRAINTS 

The test will be conducted on a closed network between MCTSSA and 
JITC; thus, there will be no connection to the Internet or any other networks. 
MCTSSA must rely on JITC’s ability to emulate the required network and 
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services expected for IPv6 testing. Specific tests that cannot be supported will 
be executed In the IPv6 lab at MCTSSA. Areas untested will be deferred to later 
events. 
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II. TEST ENVIRONMENT 


A. TEST LOCATION 

The IPv6 test will take place at MCTSSA aboard Camp Pendleton, 
California, with Defense Research Engineering Network (DREN) or Satellite 
connectivity to JITC’s simulated Standardized Tactical Entry Point (STEP) at Fort 
Huachuca, Arizona. Aboard MCTSSA, the systems under test will be located in 
Bldg-31357 lab and in the Communications (Comm) Node shelter, located on the 
south side of Bldg-31357. Transmission systems will be located in the lot north 
of Bldg-313059. 

B. TEST CONFIGURATION 

The IPv6 test will be conducted as part of Department of Defense (DoD) 
Interoperability Communications Exercise (DICE) and participating systems will 
be connected as illustrated in Figure 3. This diagram depicts the high-level 
architecture to support the test. All equipment, systems, shelters, and facilities 
will be interconnected using standard commercial and tactical interface cabling 
and transmission systems as required. 




Figure 3. 


Fligh Level Test Diagram 
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The two suites (1 and 2) depicted in Figure 3 will be configured uniquely to 
support the different scenarios and phases of testing in order to reduce the 
amount of reconfiguration required during transition between scenarios. Table 2 
lists the individual suites, associated phases, and description of the test. Suite 1 
will be configured as the legacy suite while Suite 2 will have newer Operating 
Systems (OS) and application software installed for evaluation. 


Suite 

Phase 

Description 

1&2 

Phase 1 - Functionality 

IPv4 baseline system performance 

1&2 

Phase 1 - Functionality 

Dual-Stack system performance 

2 

Phase 1 - Functionality 

IPv6 native system performance 

1&2 

Phase 2 - Conformance 

IPv6 conformance 

TBD 

Phase 3 - Security 

IPv6 security 

2 

Phase 4 - Interoperability 

Interoperability of enhanced suite 


Table 2. Phases and Objectives 


C. PARTICIPATING SYSTEMS 

The systems participating in the IPv6 test are divided into two groups. 
The first group is the SUT which includes two systems. The second group 
consists of Other Participating Systems, simulation/stimulation (sim/stim) tools, 
and data collection systems that support information and data transfer throughout 
the test architecture. Table 3 lists the hardware and software for the IPv6 test. 
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System Hardware/Software 

Qty 

System 

Hardware 

Software 

Version 

Location 

System Under Test 

2 

DDS-M 

Various 

Various 

Bldg 57 lab / Comm 
Node 

Other Participating Systems 

1 

VSAT 

VSAT-L 

N/A 

N Bldg 313059 

1 

DREN 

N/A 

N/A 

Bldg 57 lab 

Simuiation/Stimuiation 

1 

Spirent 

Test Center / Avalanche 

3.7 

Bldg 57 lab 

1 

Ixia 

IxNetwork / IxLoad / IxChariot / 
IxAnvil 

6.0 

Bldg 57 lab 

1 

Breaking Point 

Storm / Application Threat 
Intelligence 

2.2 

Bldg 57 lab 

Data Coiiection/Anaiysis 

3 

NetScout 

2U Server 

Linux 

Bldg 57 lab 

5 

Wireshark 

Laptop 

1.6.2 

Bldg 57 lab 

5 

Riverbed Cascade 
Pilot 

Laptop 

MS Win7 

Bldg 57 lab 


Table 3. System Hardware/Software and Location 


All hardware, software, and firmware versions for the SUT and other 
participating systems will be recorded and documented in the test report. 
Documentation of the appropriate versions will occur during the data collection 
period of each phase. 

1. System Under Test 

The DDS-M system enables deployed Marines to establish secure, 
networked voice, data, video conferencing and other communication capabilities 
among commanders, joint and coalition forces. Based on commercial-off-the- 
shelf equipment, the DDS-M comprises routers, switches, computers, power 
supply and other equipment needed to access the Defense Information System 
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Network (DISN), Secret Internet Protocol Router Network (SIPRNet) and Non- 
secure Internet Protocol Router Network (NIPRNet), as well as coalition and 
joint-forces networks 

2. Other Participating Systems 
a. VSAT-L 

The purpose of the SWAN-D/VSAT is to enable USMC intra-theater 
communications; to ailow forward depioyed eiements to “break” the terrestriai 
line-of-sight tether and extend their operations farther from their higher echelon 
command or to enable operations in terrain not conducive to Line-of-sight (LOS) 
operations.4 


b. DREN 

The Defense Research and Engineering Network (DREN) is DoD’s 
recognized research and engineering network. The DREN is a robust, high- 
capacity, iow-iatency nation-wide network that provides connectivity between and 
among the HPCMP’s geographically dispersed High Performance Computing 
(HPC) user sites, HPC Centers, and other networks. The DREN provides digitai, 
imaging, video, and audio data transfer services between defined service 
deiivery points (SDPs). SDPs are specified in terms of WAN bandwidth access, 
supported network protocols [Multi Protocoi Label Switching, Internet Protocol 
(IP), Asynchronous Transfer Mode (ATM)], and local connection interfaces. 


3 “General Dynamics Awarded $130 Million Contract to Produce Tactical Data Network 
Systems for the U.S. Marine Corps,” accessed Aug 6, 2011, 
http://www.gdc4s.com/news/detail.cfm?prid=285. 

4 “2010 SWAN Fact Sheet,” accessed Aug 6, 2011, 
http://www.marcorsyscom.usmc.mil/sites/cins/Fact%20Books/NSC/SATCOM/2010%20SWAN%2 
0Fact%20Sheet.pdf. 
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DREN currently supports both IP version 4 (IPv4) and IP version 6 (IPv6) at 
bandwidths from DS-3 (45 Mbps) at user sites up to OC-48c (2.488Gbps) at 
seiected HPC Centers.^ 

3. Simulation/Stimulation Tools 


a. Spirent 

Spirent’s Test Center is an application of high scaie, reaiistic traffic 
ensures that networks and components are evaiuated accurately and proven to 
perform as services scale.® Avalanche is a iine rate, 1 Gbps and lOGbps Layer 
4-7 muiti-protocoi statefui traffic performance soiution that is capable multi 
lOGbps of statefui appiication traffic generation.^ 

b. Ixia 

IxNetwork is designed to test network infrastructure, capacity, 
scaiability, and convergence providing rapid isoiation of network issues, service 
modeling at Internet scale, carrier ciass scaling, and accurate convergence 
measurement.® 

IxLoad is a scalabie solution for testing converged multiplay 
services, appiication deiivery platforms, and security devices and systems. 
IxLoad emulates data, voice, and video subscribers and associated protocois to 
ensure quaiity of experience (QoE). IxLoad also applies maiware and distributed 
denial of service (DDoS) attacks for security effectiveness and accuracy testing.® 

® “Defense Research and Engineering Network Definition,” accessed Aug 6, 2011, 
http://www.hpcmo.hpc.mil/Htdocs/DREN/dren-def.html. 

® “Spirent Test Center,” accessed Aug 6, 2011, http://www.spirent.com/Solutions- 
Directory/Spirent-TestCenter.aspx. 

^ “Avalanche,” accessed Aug 6, 2011, http://www.spirent.com/Solutions- 
Directory/Avalanche.aspx. 

® “IxNetwork for Network Topology Testing and Traffic Analysis,” accessed Aug 6, 2011, 
http://www.ixiacom.com/products/ixnetwork/index.php. 

® “IxLoad: Overview,” accessed Aug 6, 2011, 
http://www.ixiacom.com/products/ixload/index.php. 
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IxChariot is Ixia’s network assessment tool for troubleshooting 
networks and applications; it allows for simulation of real-world applications to 
predict device and system performance under realistic load conditlonsjo IxANVL 
(Automated Network Validation Library) is Ixia’s solution for automated 
network/protocol validation 

c. BreakingPoint 

The BreakingPoint Storm produces high-performance traffic from 
hundreds of real-world applications, load from millions of users, and 
comprehensive security coverage that includes thousands of current attacks and 
malware, as well as obfuscation and evasion techniques. The product features 
built-in automation to: 

• Produce a standardized Resiliency Score™ to measure network 
and data center performance, security, and stability 

• Measure the performance of massive virtualized infrastructures in 
the face of peak user load and attack 

• Validate the accuracy and performance of Lawful Intercept and 
Data Loss Prevention systems^^ 

The BreakingPoint Application and Threat Intelligence (ATI) 
program provides comprehensive application protocols and attacks, as well as 
feature updates and responsive service and support with access to the very 
latest cybersecurity updates.^3 


'*3 “ IxChariot,” accessed Aug 6, 2011, 
http://www.ixchariot.com/products/datasheets/ixchariot.html. 

'' "• “IxANVL - Automated Network Validation Library,” accessed Aug 6, 2011, 
http://www.ixiacom.com/products/ixanvl/index.php. 

''2 “BreakingPoint Storm,” accessed Aug 6, 2011, 
http://www.breakingpointsystems.com/cyber-tomography-products/breakingpoint-storm-ctm/. 

'•3 “BreakingPoint Application and Threat Intelligence,” accessed Aug 6, 2011, 
http://www.breakingpointsystems.com/cyber-tomography-products/breakingpoint-service-and- 
support/. 
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4. 


Data Collection/Analysis Tools 


a. NetScout 

Stored packet data is directly accessed with unrestricted mining 
without requiring an external server. The InfiniStream Console provides a 
streamlined view to vital data for troubleshooting high-priority issues. 

Providing granular visibility into the most complex and demanding 
network environments, nGenius Performance Manager leverages robust and 
pervasive packet flow data collected by a comprehensive family of nGenius 
intelligent data sources. Deployed across the network, nGenius intelligent data 
sources capture and analyze real-time IP traffic flows. nGenius Performance 
Manager also leverages NetFlow and sFlow data from deployed network devices 
to provide broader insight at key network aggregation points. 

b. WireShark 

Wireshark is the world’s foremost network protocol analyzer. It lets 
you capture and interactively browse the traffic running on a computer network. It 
is the de facto (and often de jure) standard across many industries and 
educational institutions. 

c. Riverbed Cascade Pilot 

Cascade Pilot is a powerful packet analysis console that 
seamlessly integrates with Wireshark, Cascade Shark and Riverbed Steelhead 
for a fully distributed, easy to manage packet capture solution for assistance in 


''4 “InfiniStream Consol,” accessed Aug 6, 2011, 

http://www.netscout.com/products/service_provider/nSAS/sniffer_analysis/Pages/lnfiniStream_Co 

nsole.aspx. 

'*5 “nGenius Performance Manager,” accessed Aug 6, 2011, 
http://www.netscout.com/products/enterprise/nSAS/ngenius_analysis/Pages/nGenius_Performan 
ce_Manager.aspx. 

''6 “About Wireshark,” accessed Aug 6, 2011, http://www.wireshark.org/about.html. 
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network troubleshooting. Fully integrated with Wireshark, Cascade Pilot uses an 
intuitive graphical user interface that maximizes user productivity by rapidly 
isolating the specific packets needed to diagnose and troubleshoot complex 
performance issues. 

D. PHYSICAL TEST ENVIRONMENT LAYOUT 

Figure 4 depicts the test lab locations and layouts for the IPv6 test 
environment. The IPv6 test will be conducted inside the lab within building 31357 
and inside an enclosed shelter on the south side of building 31357 at MCTSSA. 
External connectivity to JITC (Ft. Fluachuca) will be established via the VSAT-L, 
located in the lot north of building 313059. 


“Cascade Pilot Software,” accessed Aug 6, 2011, 
http://www.riverbed.com/us/proclucts/cascade/cascade_pilot.php. 
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C - DDS-M Suite 1 
D - VSAT-L 


Figure 4. Physical Test Environment Layout 


E. SECURITY 

lA scans of the systems under test wiii be conducted before testing 
begins. The lA process wiii confirm the system test configurations are consistent 
with the iocai approvai authority’s lA policies and DoD Security Technicai 
Information Guide (STIG) for connecting. When connecting to JITC, the resuits 
will be uploaded to the DICE portal. The JITC Designated Approving Authority is 
responsibie for ensuring the system foiiows DoD-required lA poiicies. 
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F. 


DETAILED TEST ARCHITECTURE 


Figure 5 represents the proposed network architecture that will be used 
during the test. Detailed equipment configurations for the systems involved will 
be provided in a final test report. 
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LEGEND 

ASM 

Application Service Module 

JITG 

Joint Interoperability Test Gommand 

GDI 

Gonditioned Di-phase Interface 

LEM 

Local Area Network Extension Module 

GSM 

Gommunications Security Module 

LSM 

Local Area Network Services Module 

□ ITS 

Deployable Integrated Transport Suite 

NRZ 

Non-Return-to-Zero 

DSID 

Deployed Security Interdiction Device 

PEP 

Performance Enhancing Proxy 

DSM 

Data Storage Module 

TSM 

Transition Switch Module 

ESM 

Enterprise Switch Module 

VTG 

Video Teleconferencing 

FO 

Fiber Optic 

WSM 

Wide Area Network Services Module 


Figure 5. Network Diagram 
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III. TEST DESIGN 


A. OVERALL TEST APPROACH 

The system will be tested using a logical and systematic evaluation 
sequence. This approach allows flexibility during testing and attempts to provide 
a complete picture of the current IPv6 status of the system. The goal of this test 
is to assess and report the present level of functionality (from the user 
perspective), the degree of conformance to the standards, comparative 
performance measurements, security posture, and interoperability with Joint and 
USMC Programs of Record. It is expected that the system will require multiple 
iterations of testing in order to meet full compliance. However, since this 
approach is designed to be sequential, follow-on tests of individual system 
components may not require full regression testing. 

The testing approach begins by confirming the individual system 
components and network devices provide IPv6 functionality. This functionality is 
divided into two categories, limited and basic. For the purposes of this 
document, the following definitions are provided: 

a. Limited functionality : the component or network device is capable of 
assigning an IPv6 address to the Network Interface Card (NIC), can 
successfully connect to the network, and can communicate (both 
dual-stack and IPv6 native) with other devices on the network. 

b. Basic functionality : the application or service is able to function and 
communicate (both dual-stack and IPv6 native) with other devices 
on the network. During the functionality testing, the associated 
ports and protocols used to communicate will be identified and 
recorded. 

The second area of testing is conformance. Conformance testing will be 
conducted on individual system components as stand-alone devices. Since 
system components will fall into multiple product classes, they must be evaluated 
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separately, but could be grouped together for testing. The system components 
will be tested against the appropriate product class requirements defined in the 
DoD IPv6 Standard Profiles for IPv6 Capable Products Version 6.0. 

The third area of testing is performance. Performance testing wiii be 
conducted on servers and network devices. The resuits will provide a basis for 
comparison between the network implementations (IPv4, dual-stack, and IPv6). 
Examples of the performance metrics to be recorded and anaiyzed include: 
application response time, transactions per second, packet loss, latency, jitter, 
and throughput. These metrics will be maintained for future anaiysis or 
comparison during subsequent testing. 

The fourth area of testing is security. Host system, server, switch and 
router security testing is inciuded in the conformance testing, since the IPv6 
security feature requirements are currently defined for each of the product 
ciasses. Information Assurance (lA) devices have unique requirements defined 
and wiii not be inciuded at this time. 

The finai area of testing is interoperabiiity. Interoperability testing includes 
both internal (MAGTF) and external (Joint). Functional testing of the 
application(s), service(s), transport, and routing provides the basis for internai 
interoperability. Joint interoperability will expand the functional testing by 
evaiuating interfaces with joint applications, services, transport, and routing. 

For this test, one suite will be configured as a legacy (fielded) system and 
the second will be configured as an enhanced suite. Exampies of the differences 
on the enhanced suite inciude, but are not limited to: servers running Windows 
Server 2008 and Exchange 2010 installations and routers/switches upgraded to 
newer Cisco Internetwork Operating System (lOS). 

B. PLANNED TESTS 

The test will be conducted in phases as described in the following 
paragraphs. Phase 1 wiii focus on functionaiity, performance and 
interoperabiiity. During this phase of testing, interoperability of voice, video, and 
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data transmissions between end devices will be evaluated. Functionality and 
interoperability testing will Include client-to-server, server-to-server, and 
SIM/STIM communications as listed in Table 4. Phase 2 will be conformance 
testing of individual system components. Phase 3 will be detailed/scheduled at a 
later time to assess the security devices within the system. Phase 4 will focus on 
joint Interoperability. This phase can be combined as part of Phase 1 or 
scheduled as a separate phase, to support JITC testing. 


Source 

Destination 

Service 

Workstation 1 (local) 

Workstation 2 (remote) 

VTC, Ping, Trace-route, Email 

Workstation 2 (remote) 

Workstation 1 (local) 

VTC, Ping, Trace-route, Email 

Workstation 1 (local) 

Server 2 (remote) 

HTTP, HTTPS, SSH, FTP, FTPS 

Workstation 2 (remote) 

Server 1 (local) 

HTTP, HTTPS, SSH, FTP, FTPS 

Server 1 (local) 

Server 2 (remote) 

Mail, VoIP 

Server 2 (remote) 

Server 1 (local) 

Mail, VoIP 

SIM/STIM 1 (local) 

SIM/STIM 2 (remote) 

RFC 2544, Network Loading & Layer 4- 
7 

SIM/STIM 2 (remote) 

SIM/STIM 1 (local) 

RFC 2544, Network Loading & Layer 4- 
7 


Table 4. Source, Destination, and Service 


1. Phase 1: Performance 

Phase 1 testing will be divided into three different network scenarios (IPv4, 
dual-stack, and IPv6 native). For each scenario, the complete set of test 
procedures will be executed on both suites of equipment. Table 5 depicts the 
Cisco Internetwork Operating Systems (lOSes) on the 3845 Routers and 3750G 
Switches as well as the Operating Systems (OSes) on the servers. Suite 1 is 
configured as is currently fielded to Marines using the system in tactical 
environments. Known issues exist with the lOS version and OSes; they are not 
IPv6 capable. Suite 2 is configured as the engineers at MCTSSA and SYSCOM 
have deemed to be the best-case scenario for deployment of the DDS-M. 
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Network Scenario 

SUITE 1 

SUITE 2 

Scenario 1: IPv4 

Router: 12.4(15)713, w/AdvEntServices 

Switch: 12.2(50)SE4, w/ IP Services 

Servers: Windows Server 2003 

Exchange: Microsoft Exchange 2003 

Router: 12.4(15)714, w/AdvEntServices 

Switch: 12.4(50)SE4, w/ IP Services 

Servers: Windows Server 2008 

Exchange: Microsoft Exchange 2010 

Scenario 2: Dual Stack 

Scenario 3: IPv6 Native 


Table 5. Configuration Differences Between Suites 


The Modules mainly affected by the above table are the LAN Extension 
Module (LEM), Enterprise Switch Module (ESM) and the LAN Services Module 
(LSM) for the Switch lOSes. The WAN Services Module (WSM) is the only 
module affected by the Router lOSes. The Application Service Module (ASM) 
and the Data Storage Module (DSM) are the Modules mainly affected by the 
Operating Systems (Microsoft Server and Microsoft Exchange). 

Table 6 is a test matrix which highlights (via shading) the types of tests 
applicable to each of the product classes. The shaded cells grouped together 
identify when the metric is a result (or summary) of both client and server 
action(s). The table is further broken down to depict both user and performance 
metrics. The user metrics will be used for the overall pass/fail criteria, while the 
performance metrics will be used for the comparative analysis between the 
scenarios. 


a. Scenario 1 

The legacy suite (Suite 1) and enhanced suite (Suite 2) will be 
configured for an IPv4 based network. User and performance metrics will be 
captured and recorded. The performance metrics will become the baseline 
values for comparison. 


20 




b. Scenario 2 

The systems and network devices will be re-configured for dual¬ 
stack operations (IPv4 and IPv6 protocols enabled). The user and performance 
metrics will be captured, recorded, analyzed and compared against the baseline 
results for Scenario 1. 

c. Scenario 3 

The systems and network devices will be re-configured for IPv6 
native operations (IPv6 enabled and IPv4 disabled). The user and performance 
metrics will be captured, recorded, analyzed and compared against the results 
for Scenarios 1 and 2. 
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Highlighted cells identify what applies to each sub-category of the 
objectives. This applies to the system and individual components. 

User Metrics 

Performance Metrics 

IPv6 

Functionality 

Application 

Application 

Network 

Objective 

Application or Category 
Client/server 

Protocol 
(Dost. Port) 

Transport 

(Protocol 

#) 

Limited Functions 

(IP Addressing) 

Basic Functions 

(Application support) 

Message Completion 

Threshold>=90%, 

Objective>=90% 

Data Integrity 

Threshold>=99.9% 

Objective>=99.9% 

Call Completion rate 

Application Response 

Time 

Transactions per 

Second 

Voice Ouality Mean 

Opinion Score (MOS) 

Video/Voice Quality 

Mean Opinion Score 

Application Response 

Time 

Packet Loss 

Latency 

Jitter 

Throughput 

Applications and Services - End Nodes (Host/Workstations, Network Appliance, Server (Advanced, Simple)) 


Web-based transactions 
















Client (Internet 

Explorer) 

HTTP (80) 

TCP (6) 
















Server (IIS) 

HTTP (80) 

TCP (6) 










Client (Internet 

Explorer) 

HTTPS (443) 

TCP (6) 
















Server (IIS) 

HTTPS (443) 

TCP (6) 










Domain Name System resolution 
















Client 

DNS query (53) 

UDP (17) 
















Server 

DNS response 
(53) 

UDP(17) 










Server 

DNS zone 

transfers (53) 

TCP (6) 
















Mail Exchange 
















Client (Outlook) 

IMAP/RPC 

TCP (6) 
















Server (Exchange) 

IMAP/RPC 

TCP (6) 














Server (Exchange) 

SMTP (25) 

TCP (6) 
















Client 

POP-3 (110) 

TCP (6) 
















Client 

SMTP (25) 

TCP (6) 
















File Transfer 
















Client/IE or FTP client 

FTP (20,21) 

TCP (6) 
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Highlighted cells identify what applies to each sub-category of the 
objectives. This applies to the system and individual components. 

User Metrics 

Performance Metrics 

IPv6 

Functionality 

Application 

Application 

Network 

Objective 

Application or Category 
Client/server 

Protocol 
(Dest. Port) 

Transport 

(Protocol 

#) 

Limited Functions 

(IP Addressing) 

Basic Functions 

(Application support) 

Message Completion 

Threshold>=90%, 

Objective>=90% 

Data Integrity 

Threshold>=99.9% 

Objective>=99.9% 

Call Completion rate 

Application Response 

Time 

Transactions per 

Second 

Voice Quality Mean 

Opinion Score (MOS) 

Video/Voice Quality 

Mean Opinion Score 

Application Response 

Time 

Packet Loss 

Latency 

Jitter 

Throughput 


Server/IIS 

FTP (20,21) 

TCP (6) 
















Client (FTP Secure) 

FTPS (TLS/SSL- 
) 

TCP (6) 
















Server/IIS 

FTPS (TLS/SSL- 
) 

TCP (6) 














Client (Secure Copy) 

SCP (SSH-22) 

TCP (6) 
















VoIP 
















Cisco Call Manager 

H.323 (multiple) 

TCP/UDP 
















End User Device 

H.323 (multiple) 

TCP/UDP 










SIP Server 

SIP (5060) 

TCP/UDP 
















End User Device 

SIP (5060) 

TCP/UDP 










VTC 
















Video call 

H.323 (multiple) 

TCP/UDP 
















Management/etc 
















Ping/Traceroute 

ICMP 

ICMP (1) 
















Ping V6 

ICMPv6 

ICMP 

(58) 
















Secure Shell 

SSH (22) 

TCP (6) 
















Network Time Client 

NTP (123) 

UDP (17) 
















Network Time Server 

NTP (123) 

UDP (17) 
















Network Management 
Client 

SNMP (161) 

UDP (17) 
















Network Management 
Server 

SNMP trap (162) 

UDP (17) 
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Highlighted cells identify what applies to each sub-category of the 
objectives. This applies to the system and individual components. 

User Metrics 

Performance Metrics 

IPv6 

Functionality 

Application 

Application 

Network 

Objective 

Application or Category 
Client/server 

Protocol 
(Dost. Port) 

Transport 

(Protocol 

#) 

Limited Functions 

(IP Addressing) 

Basic Functions 

(Application support) 

Message Completion 

Threshold>=90%, 

Objective>=90% 

Data Integrity 

Threshold>=99.9% 

Objective>=99.9% 

Call Completion rate 

Application Response 

Time 

Transactions per 

Second 

Voice Quality Mean 

Opinion Score (MOS) 

Video/Voice Quality 

Mean Opinion Score 

Application Response 

Time 

Packet Loss 

Latency 

Jitter 

Throughput 


Dynamic Host 

Configuration Client 

DHCP (67,68) 

UDP (17) 
















Dynamic Host 

Configuration Server 

DHCP (67,68) 

UDP (17) 
















Trivial File Transfer 
Client 

TFTP (69) 

UDP (17) 
















Trivial File Transfer 
Server 

TFTP (69) 

UDP (17) 













Transport and Routing - Intermediate Node (Router, L3 Switch) 


Transport 


















Ping/Traceroute 

ICMP 

ICMP (1) 
















IPv4 Multicast Group 
Management 

IGMP 

IGMP (2) 
















Ping V6 

ICMPv6 

ICMP 

(58) 

















ND (Node 

Discovery) 

ICMP 

(58) 

















MRD (Multicast 
Router 

Discovery) 

ICMP 

(58) 

















Authentication 
Header (AH) 

AH (51) 

















Encap Security 
Payload (ESP) 

ESP (50) 
















Routing 
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Highlighted cells identify what applies to each sub-category of the 
objectives. This applies to the system and individual components. 

User Metrics 

Performance Metrics 

IPv6 

Functionality 

Application 

Application 

Network 

Objective 

Application or Category 
Client/server 

Protocol 
(Dest. Port) 

Transport 

(Protocol 

#) 

Limited Functions 

(IP Addressing) 

Basic Functions 

(Application support) 

Message Completion 

Threshold>=90%, 

Objective>=90% 

Data Integrity 

Threshold>=99.9% 

Objective>=99.9% 

Call Completion rate 

Application Response 

Time 

Transactions per 

Second 

Voice Quality Mean 

Opinion Score (MOS) 

Video/Voice Quality 

Mean Opinion Score 

Application Response 

Time 

Packet Loss 

Latency 

Jitter 

Throughput 



EIGRP 

(224.0.0.10) 

EIGRP 

(88) 

















OSPF 

(224.0.0.5,6) 

OSPF 

(89) 

















BGP (179) 

TCP (6) 
















Table 6. Functionality Test Matrix 
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2 . 


Phase 2: Conformance 


Phase 2 testing will be stand-alone conformance testing of the individual 
system components. The system is comprised of both end nodes and network 
devices. These components are categorized in different Product Classes and 
have unique conformance test requirements. These test requirements can be 
found in the DDS-M Test Procedures at MCTSSA (MCTSSA IPv6 Test 
Procedures) and are an excerpt from Section 3 of the DoD IPv6 Standard 
Profiles for IPv6 Capable Products Version 6.0. The Spirent Test Center and Ixia 
Conformance applications will be used to evaluate the component against the 
applicable RFCs and standards. 

Each individual module of the DDS-M will be tested by itself against the 
Conformance applications of the test tools being used. The configurations of the 
Suites will remain the same from Phase 1 (Suite1=Legacy and 
Suite2=Enhanced). 

3. Phase 3: Security 

Phase 3 testing will be security testing of the security or lA devices within 
the system. This phase will be scheduled at a later time, as the requirements are 
still evolving. 

4. Phase 4: Interoperability 

Phase 4 testing will be interoperability testing of the system. This will 
include both internal (MAGTF) and external (Joint) interoperability. 
Interoperability testing can be scheduled as part of Phase 1 or as a separate 
phase to support unique JITC testing requirements. JITC normally tests voice, 
video and data exchanges between USMC and Joint systems. For the purpose 
of this thesis. Interoperability will be tested alongside Phase 1. JITC has test 
scripts that emulate OSI Layers 2-4 on Joint Systems and those will be used for 
the Interoperability Phase. 
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c. 


EVALUATION CRITERIA 


The evaluation criteria for each test case or requirement is provided in the 
Internet Protocol version 6 Test Procedures (MCTSSA IPv6 Test Procedures). 
Each requirement will be evaluated with either Pass (P) or Fail (F). “Pass” 
indicates the requirement was met. “Fail” indicates the requirement was not met. 
The user metrics and interoperability test results will be evaluated against DoD 
specifications identified in Tables 7 and 8, provided by JITC. 


IE 

# 

Name 

Producer/ 

Sender 

ID 

Consumer/ 

Recipient 

ID 

Critical 

Interface 
Ref (See 
Table 4- 
4) 

Criteria 

Threshoid 

Objective 

1 

Unclassified 

Data 

Server 

1 

Workstation 

1 

Yes 

11 

> 90% 
Transmitted, 

> 99.9% 

Data 

Integrity 

> 90% 
Transmitted, 

> 99.9% 

Data 

Integrity 


LEGEND: 

I Interface IE Information Exchange 

ID Identification Ref Reference 


Table 7. Information Exchange Requirements 


1# 

Interface 

Version 

Critical 

KIP 

Criteria 

Threshoid 

Objective 

11 

Switch/Router Port 


Yes 

N/A 

> 90% Transmitted, > 
99.9% Data Integrity 

> 90% 
Transmitted, 

> 99.9% Data 
Integrity 


LEGEND: 

I Interface 

KIP _ Key Interface Profile 


Table 8. Information Exchange Thresholds Requirements 


D. PROBLEM REPORTING 

All incidents, anomalies, problems, or failures observed during the test will 
be reported via a Trouble Incidence Report (TIR) and recorded in a daily test log. 
Information from the Daily Test Logs will be combined into a Master Test Log 
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upon completion of the event. The notes from the test logs, TIRs and collected 
data will be used for problem analysis. The result of the analysis will be reported 
in the final test report. All generated TIRs will be archived in the MCTSSA 
Configuration Management library. 

E. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS 

No suspension criteria or resumption requirements have been established. 
Individual test cases may require suspension, resumption, or possibly 
termination. The decision to suspend or resume testing will be made by the Test 
Director and Team Lead. 

F. TEST SCHEDULE 

Table 9, Plan of Action and Milestones (POA&M), identifies a tempiate for 
the test scheduie from planning through reporting. The start and finish dates 
should be actual dates and the duration period shouid represent calendar days. 
The due date listed will be the original due date listed from the Test Plan or 
adjusted due date based on the approved deviation extending the test. 


POA&M 

Task Name 

Start 

Finish 

Duration 

Due Date 

Status 

Comments 

IPv6 Test 







Team kick-off 







Develop Test Plan 







Test Readiness Review 







Prepare Test Lab 







Execute Test 







Data Analysis 







Develop Draft Test Report 







QA Review 







TCG review / Adjudication 







Review and Route 







Test Report Signed 








Tabie 9. POA&M 
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IV. CONCLUSION AND RECOMMENDATIONS 


A. FUTURE WORK AT MCTSSA 

1. The Foundation has been Laid 

Once the DDS-M completes testing, all other tactical programs of record 
will be tested behind (while attached to) the DDS-M. Preliminary tests indicate 
that the DDS-M will have no issues with passing the Dual Stacked portions of the 
requirements in the USMC IPv6 Transition Plan, so a lab has been built that will 
emulate the DDS-M at MCTSSA. 

The test plan laid out goes into great detail for functionality and 
performance testing Layers 2-4 of the OSI Model on the DDS-M. Further 
research needs to be conducted into the area of IPv6 Security; the focus of this 
thesis is on performance, conformance, and interoperability, but Security should 
not be neglected in follow on work(s). 

2. The Need for an IPv6 Lead 

A need exists at MCTSSA to lead this efforts. Headquarters Marine Corps 
is pushing this effort, but the Programs of Record rely on MCTSSA to perform the 
appropriate testing for this transition. The ideal individual to occupy this billet will 
meet the below requirements: 

• Marine Corps Captain 

• Information Technology Management and/or a Computer Science 
Masters Degree 

• Communications Officer (0602) Military Occupation Specialty 

• Deployed and/or Combat Experience 
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